Distributed process control systems, like those used in chemical, petroleum, industrial or other process plants to manufacture, refine, transform, generate, or produce physical materials or products typically include one or more process controllers communicatively coupled to one or more field devices via analog, digital or combined analog/digital buses, or via one or more wireless communication links or networks. The field devices, which may be, for example, valves, valve positioners, switches and transmitters (e.g., temperature, pressure, level and flow rate sensors), are located within the process environment and generally perform physical or process control functions such as opening or closing valves, measuring process and/or environmental parameters such as temperature, flow, or pressure, etc., to control one or more processes executing within the process plant or system. Smart field devices, such as the field devices conforming to the well-known Fieldbus protocol may also perform control calculations, alarming functions, and other control functions commonly implemented within the controller. The process controllers, which are also typically located within the plant environment, receive signals indicative of process measurements made by the field devices and/or other information pertaining to the field devices and execute a controller application that runs, for example, different control modules which make process control decisions, generate control signals based on the received information and coordinate with the control modules or blocks being performed in the field devices, such as HART®, WirelessHART®, and FOUNDATION® Fieldbus field devices. The control modules in the controller send the control signals over the communication lines or links to the field devices to thereby control the operation of at least a portion of the process plant or system, e.g., to control at least a portion of one or more industrial processes running or executing within the plant or system. I/O devices, which are also typically located within the plant environment, typically are disposed between a controller and one or more field devices, and enable communications there between, e.g., by converting electrical signals into digital values and vice versa. As utilized herein, field devices, controllers, and I/O devices are generally referred to as “process control devices,” and are generally located, disposed, or installed in a field environment of a process control system or plant.
Still further, in many process or industrial plants, the process control network includes a safety instrumented system (SIS) which operates to detect significant safety related problems within the process plant and to automatically close or open valves, remove power from devices, switch flows within the plant, etc., when a problem occurs which might result in or lead to a serious hazard in the plant, such as a spill of toxic chemicals, an explosion, etc. These safety systems typically have one or more separate controllers apart from the standard process control controllers, called safety system logic solvers, which are connected to safety field devices via separate buses, communication lines, or wireless networks installed within the process plant. The logic solvers execute safety instrumented function (SIF) routines that use the safety field devices to detect process conditions associated with significant events, such as the position of certain safety switches or shutdown valves, overflows or underflows in the process, the operation of important power generation or control devices, the operation of fault detection devices, etc., to thereby detect events within the process plant. When an event, which may be a single condition or the simultaneous occurrence of two or more conditions, is detected, the safety controller takes some action to limit the detrimental nature of the event, such as closing valves, turning devices off, removing power from sections of the plant, etc. Generally, these actions include switching safety devices into a tripped or “safe” mode of operation which is designed to prevent a serious or hazardous condition within the process plant.
In both cases, information from the field devices, the controllers, and the safety system logic solvers (also called safety controllers) is usually made available over a data highway or communication network to one or more other hardware devices, such as operator workstations, personal computers or other types of computing devices with user interfaces, data historians, report generators, centralized databases, or other centralized administrative computing devices that are typically placed in control rooms or other locations away from the harsher field environment of the plant, e.g., in a back-end environment of the process plant. Each of these hardware devices typically is centralized across the process plant or across a portion of the process plant. These hardware devices run applications that may, for example, enable a control or a safety system operator to perform functions with respect to controlling a process and/or operating the process plant, such as changing settings of the process control routine or a safety routine, modifying the operation of the control modules within the process controllers, the safety system controllers, the field devices, etc., viewing the current state of the process, viewing alarms generated by field devices, the process controllers, or the safety system controllers, simulating the operation of the process for the purpose of training personnel or testing the process control software, keeping and updating a configuration database, etc. The data highway utilized by the hardware devices, controllers, and field devices may include a wired communication path, a wireless communication path, or a combination of wired and wireless communication paths.
As an example, the DeltaV™ control system, sold by Emerson Process Management, includes multiple applications stored within and executed by different devices located at diverse places within a process plant. A configuration application, which resides in one or more workstations or computing devices in a back-end environment of a process control system or plant, enables users to create or change process control modules and download these process control modules via a data highway to dedicated distributed controllers. Typically, these control modules are made up of communicatively interconnected function blocks, which are objects in an object oriented programming protocol that perform functions within the control scheme based on inputs thereto and that provide outputs to other function blocks within the control scheme. The configuration application may also allow a configuration designer to create or change operator interfaces which are used by a viewing application to display data to an operator and to enable the operator to change settings, such as set points, within the process control routines. Each dedicated controller (such as the process controllers and the safety system controllers) and, in some cases, one or more field devices, stores and executes a respective controller or safety application that runs the control modules assigned and downloaded thereto to implement actual process control and safety system functionality.
Moreover, one or more user interface devices, or plant display applications which may be executed on one or more user interface devices, such as operator workstations, one or more remote computing devices in communicative connection with the operator workstations and the data highway, etc., receive data from the controllers and the field devices via the data highway and display this data to process control system designers, operators, or users via a user interface screen. These user interface devices or applications may provide any of a number of different views, such as an operator's view, an engineer's view, a technician's view, etc. tailored to actions performed by different users in the plant. Moreover, a data historian application is typically stored in and executed by a data historian device that collects and stores some or all of the data provided across the data highway while a configuration database application may run in a still further computer attached to the data highway to store the current process control routine configuration and data associated therewith. Alternatively, the configuration database may be located in the same workstation as the configuration application.
One of the important activities performed by control and or safety system operators, maintenance system operators, etc., relates to viewing and responding to alarms that are generated by the various devices, control routines, safety system routines, maintenance routines, etc., during operation of the plant. Generally speaking, process control operators, safety system operators, maintenance personnel, etc., view a user interface display screen provided by a user interface application that is executed on a workstation, a handheld device, etc., generally within the back-end environment of the plant away from the actual field devices and other field equipment within a field environment of the plant. During the operation, the user interface application may present one of a number of possible preconfigured plant displays to the user, wherein each plant display typically depicts some area, unit, section, or other part of the plant. As is commonly known, physical process elements (such as valves, sensors, etc., that are to be utilized to control a process in a process plant) may be depicted in accordance with Piping and Instrumentation Diagrams (P&IDs) and/or other plans or “blueprints” of the plant floor layout and/or of the process control system or the safety system layout. Additionally, these user interface applications typically display an alarm banner or other alarm display that indicates some or all of the various alarms that have been generated or initiated by devices and logic modules within the plant, such as device alarms generated by smart devices within the plant, control alarms generated by control routines or modules within the controllers (such as the process and safety system controllers) in the plant, maintenance alarms generated by devices or maintenance applications running the plant, etc. The alarm banner typically depicts an icon associated with each alarm that has been initiated within the plant, and these icons may be organized, color coded, displayed as solid or blinking icons, etc., based on a severity, priority, location, or other criteria, of the alarm or of the source of the alarm.
Generally speaking, the user is able to click on the alarm in the alarm banner and immediately be provided with a preset user interface depiction associated with the alarm that enables a user, such as control system operator, to view the state of the process or equipment related to the alarm. Such a display may be a plant display in the form of, for example, a PI&D diagram, a faceplate display of a device or module, other information about a device or module, etc., that generated the alarm. However, in the typical alarm display system, the alarm identification, description, and alarm viewing and display navigation attributes are, by default, determined by the general properties of the container or the source of the alarm, wherein the container may be a control module, a safety system module, an equipment module, a control system element, a field device, etc. Thus, alarms associated with a control module, for example, are tied to the general alarm handling properties of the control module from which these alarms originated. As such, when an alarm is displayed in an alarm banner on a user interface, clicking on the alarm brings up a plant display and/or a faceplate display associated with the control module that generated the alarm. However, in many cases, the preconfigured display for the control module associated with or in which the alarm was generated may not be the best graphical or other type of information to provide to the user to enable the user to best deal with the particular alarm. This fact is especially true in safety systems, in which the alarms being generated by a particular safety system module may deal with many different devices or other sources in the plant that are not shown well or are that are not shown at all in the plant display associated with the safety module that generated the alarm.
As one example, a module A that runs a process may have a single plant display DA and an associated faceplate display FPA. However, the operation of the module may incorporate or use two sub-modules A1 and A2, each of which may have its own associated plant display (e.g., DA1 and DA2, respectively), and its own associated faceplate display (FPA1 and FPA2, respectively). The plant displays (DA1 and DA2) and the faceplate displays (FPA1 and PFA2) for the sub-modules A1 and A2 may depict different and/or more information than the plant display (DA) and the faceplate display (FPA) for the module A. However, clicking on an alarm in an alarm banner associated with the module A (in which the alarm was generated), regardless of whether the alarm was actually generated by sub-module A1 or A2, would automatically navigate to the plant display DA and to the faceplate display FPA. If the alarm related to a particular transmitter that is within the sub-module A1 but that is not depicted in the module plant display DA or the module faceplate display FPA, the user will not see the source of the alarm in the plan display or the faceplate display which is then presented to the user as a result of the user selecting the alarm. In fact, in this case, a user might prefer that, by clicking on the alarm in the alarm banner, that the user interface system navigate to the plant display DA1 and to the faceplate display FPA1, because that is where the transmitter with relevant information about the alarm is depicted. In this case, the user must now manually navigate to the more desirable displays, which takes time and skill.
Presently, if a user wants to circumvent this issue, the user creates a separate “shadow” alarm display module that mirrors the control module, but with a separate alarm (which is in fact, a duplicate alarm of the control module) or a subset of alarms (again all of which are duplicate alarms of the control module) which mirror the alarms within the actual control module, and then clicks the alarm generated by the “shadow” alarm display module to cause the user interface display to navigate to the desired plant display and faceplate display of the “shadow” alarm display module, for example, to the plant display DA1 and to the faceplate display FPA1. This work-around requires additional memory, additional loading on the processor and thus additional processor execution cycles, etc., and requires additional programming, all of which are inefficient within the computer operation. This work-around also results in duplicate alarms being generated by two, basically redundant modules, and requires the user to know which alarm to use to navigate to the desired display.